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Status of this Memo 


This memo provides information for the Internet community. It does 
not specify an Internet standard of any kind. Distribution of this 
memo is unlimited. 


Copyright Notice 
Copyright (C) The Internet Society (2003). All Rights Reserved. 
Abstract 


This document contains the text of the agreement signed between 
ISOC/IETF and ISO/IEC JTC1/SC6 regarding cooperative development of 
the IS-IS routing protocol. The agreement includes definitions of 
the related work scopes for the two organizations, request for 
creation and maintenance of an IS-IS registry by IANA, as well as 
collaboration guidelines. 


Document Header 


Annexe 1 to Cooperative Agreement Between the Internet Society and 
the International Organization for Standardization / International 
Electrotechnical Commission / Joint Technical Committee 1 / Sub 
Committee 6 (ISO/IEC JTC1/SC6): IS-IS Routing Protocols 


Date: 2003-01-28 
This annexe records the agreed collaborative process for the further 
development and standardisation of the Intermediate System to 
Intermediate System (IS-IS) intra-domain routing protocol (ISO/IEC 
10589). 

1. Introduction 
The IS-IS intra-domain routing protocols, originally developed in 


ISO/IEC/JTC1/SC6, have been successfully deployed in the Internet for 
several years. 
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2. 


ISO/IEC/JTC1/SC6 is the JTC1 sub-committee which has responsibility 
for maintenance of the IS-IS standard (ISO/IEC 10589). 


The IS-IS Working Group of the IETF is chartered to develop 
extensions to the IS-IS protocol to be used within the scope of the 


Internet. 


This addendum documents the agreed process for the future development 
of IS-IS by both organizations. 


Definitions 


2.1 Core IS-IS Mechanisms 


Core IS-IS Mechanisms are subsystems with associated algorithms, data 
structures, and PDU formats as specified in (ISO/IEC 10589), 
constituting the core of the IS-IS protocol and including the 
following elements: 

a) Framework of PDU formats, including TLVs defined in [10589] 

b) Encapsulation of PDUs 

c) Adjacency state machine and formation logic 

d) DIS election algorithm 

e) Initial LSP synchronization via CSNP exchange 


f) Asynchronous LSP flooding (including DIS flooding behavior) 


g) LSP database maintenance including LSP origination, aging, and 
purging 


h) Topology abstraction defined in [10589] 


2.2 Internet-specific IS-IS Extensions: 


Internet-specific IS-IS Extensions are extensions to the IS-IS 
protocol that are within the work scope of the IETF including any 
routing or packet forwarding technology that the IETF decides to work 
on in the future (such as IPv4 or IPv6 unicast and multicast routing, 
MPLS, MPLS Traffic Engineering, or Generalized MPLS), and: 


a) do not modify the Core IS-IS Mechanisms and do not change 
operation of non-IP or affect compatibility with non-IP and dual 
implementations of IS-IS, or 
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b) add supplementary mechanisms to the Core IS-IS Mechanisms, are not 
generally applicable to non-IP implementations of IS-IS, and do 
not change operation of non-IP or affect compatibility with non-IP 
and dual implementations of IS-IS, or 


c) are de facto implementation agreements that are not generally 
applicable to non-IP implementations of IS-IS. 


Note that the introduction of new TLVs or sub-TLVs that do not modify 
the algorithms of the Core Mechanisms in a way that would affect 
interoperability with non-IP or dual implementations of IS-IS is not 
considered to be a modification to the Core IS-IS Mechanisms. 


3. Agreement 
The following conventions are used in the rest of this document. 


SHALL This term is used to indicate commitment to follow a 
specific element of this agreement. 


MUST Equivalent to "SHALL" 


SHALL NOT This phrase is used to indicate commitment to NOT perform 
a specific action 


MAY This term is used to indicate the right to perform a 
specific action 


SHOULD This term is used to indicate that following a specific 
element of this agreement is encouraged, however there may 
exist circumstances in which a decision may be made not to 
do so. 


3.1 Separation of IS-IS Work Scope 


JTC1 SHALL NOT and IETF MAY (subject to the IETF standards process) 
standardize any Internet-specific IS-IS Extensions. 


Any IS-IS Extensions produced within the IETF that require 
standardization, but cannot be identified as Internet-specific per 
section 2.2 of this document SHOULD be submitted for standardization 
to JTC1 (see section 3.3.2). IETF SHALL NOT publish documents 
describing such IS-IS extensions other than as Informational RFCs. 


Zinin Informational [Page 3] 


RFC 3563 IETF - JTC1 Agreement on IS-IS July 2003 


IS-IS extensions submitted from the IETF to JTC1 will be processed 
under the JTC1 fast track procedure. To ensure the quality of such 
submissions, IETF SHALL apply to them the procedures for Proposed 
Standard submission according to [RFC2026] (even though these 
documents will not be published as standards-track IETF RFCs). 


In the situations where it is not clear from the provisions of this 
document whether a specific protocol extension should be standardized 
within the IETF or within JTC1, the decisions will be made on a case- 
by-case basis and will be based on the agreement between the two 
organizations reached via a discussion between the IETF Routing Area 
Directors or the IETF liaison to JTC1/SC6 (who will reflect the IETF 
consensus on the matter), and the JTC1/SC6 secretariat. 


3.2 Requirements for IS-IS-specific IETF documents 


All IS-IS-related IETF documents intended to be published as IETF 
standards track RFCs MUST include a section explaining why they 
qualify to be considered as Internet-specific IS-IS Extensions 
described in section 2.2 of this document. 


3.3 IS-IS Registries (IANA Considerations) 
3.3.1 IS-IS TLV Codepoint Registry 


Until JTC1 provides the registry service for IS-IS, IANA is requested 
to temporarily maintain such a registry as described below. Upon 
notification from JTC1, the registry management authority (i.e., 
value allocation) will be transferred to JTC1. IANA MAY still retain 
the registry for informational purposes and keep updating it based on 
information provided by JTC1. 


TANA has created and currently maintains a registry for IS-IS TLV 
codepoints. The range of values is 0-255. Initial state of the 
registry should be synchronized with [RFC3359]. Allocation of values 
in the registry has to be approved by the designated expert assigned 
by the IESG. IETF SHALL keep JTC1/SC6 informed of TLV codepoint 
values allocated, and JTC1/SC6 SHALL refer allocation requests 
arising within JTC1 constituencies to the IANA registry process. 


3.3.2 IETF-specific Registries 
IETF MAY request IANA to maintain IS-IS-related registries if those 


are required to maintain name spaces internal to Internet-specific 
IS-IS extensions. 
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3.4 Collaboration Guidelines 
3.4.1 Learning About New Work 


IETF SHALL inform the chairman and secretariat of ISO JTC 1/SC 6 
about new IS-IS-related work items. 


JTC1/SC6 SHALL inform the IETF Routing Area directors and ISIS WG 
chairs about new IS-IS-related work items. Communication MAY be 
enacted directly using electronic mail, or may be conducted via 
appointed SC6 / IETF liaison representatives. 


3.4.2 Submitting IETF Documents to JTC1 


As a class A liaison organisation to JTC1, the Internet Society may 
submit existing standards for adoption as International Standards of 
the ISO, using the Fast-Track procedure. 


IS-IS extensions developed by IETF and intended for standardization 
in JTC1 according to section 3.1 SHOULD therefore be submitted by one 
of the IETF ISIS WG chairs, or an IETF Routing Area director, sending 
an email message to the secretariat of ISO JTC 1 specifying the 
number of the Informational RFC containing the specification (the 
document MUST have been published as an RFC at the time of 
submission) and requesting fast-track processing by JTC1. The full 
text of the specification is then available using the following URL: 


http://www.ietf.org/rfc/rfcNNNN.txt 


where "NNNN" is the number of the RFC being submitted. The IETF 
SHOULD also recommend that JTC1 assign the document to JTC1/SC6, and 
SHOULD also submit to JTC1 the name of an individual who is prepared 
to serve as project editor for the fast-track document. 


3.4.3 Submitting JTC1 Documents to IETF 


It is possible to make JTC1 standards specifications available for 
informational purposes of the IETF community by submitting the text 
of the specification as an Internet Draft and requesting the RFC 
Editor to publish the document as an Informational RFC. See sections 
4.2.2 and 7 of [RFC2026] for more information. Guidelines for 
Internet Draft preparation are given in [ID-GUIDE]. 


3.4.4 Mutual Document Review 
Members of ISO JTC 1/SC 6 are welcome to review any IS-IS-related 


IETF document (all IETF documents are publicly available at the IETF 
web site) and submit their comments to the ISIS WG (by sending an 
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email to the working group mailing list), the ISIS WG chairs (see 
[ISISWG] for more information), the IETF Routing Area directors, or 
the IESG (iesg@ietf.org). 


JTC1 is encouraged to request an IETF review of IS-IS-related work 
performed by JTC 1/SC 6 by submitting the text of the document as an 
informational Internet Draft (see section 3.3.2) and sending a 
message to the IETF ISIS WG mailing list requesting the comments. 


The IETF MAY request JTC1 to circulate provided comments among the 
National Bodies and Liaison Organizations involved in the discussion 
of the work under review. 
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8. Full Copyright Statement 
Copyright (C) The Internet Society (2003). All Rights Reserved. 


This document and translations of it may be copied and furnished to 
others, and derivative works that comment on or otherwise explain it 
or assist in its implementation may be prepared, copied, published 
and distributed, in whole or in part, without restriction of any 
kind, provided that the above copyright notice and this paragraph are 
included on all such copies and derivative works. However, this 
document itself may not be modified in any way, such as by removing 
the copyright notice or references to the Internet Society or other 
Internet organizations, except as needed for the purpose of 
developing Internet standards in which case the procedures for 
copyrights defined in the Internet Standards process must be 
followed, or as required to translate it into languages other than 
English. 


The limited permissions granted above are perpetual and will not be 
revoked by the Internet Society or its successors or assigns. 


This document and the information contained herein is provided on an 
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 
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